Packets in a bitstream are often delineated by the appearance therein of a particular data value, e.g. a particular 8-bit wide (byte or octet) data pattern, which is termed the “synchronization pattern”. For example, according to the MPEG-2 standard used for Digital Video Broadcasting (DVB), the 8-bit value used for the synchronization pattern of the transport bitstream is 0x47 (01000111). The transport bitstream is based upon packets of constant size so that adding error-correction codes and interleaving in a higher layer is eased. The format of a transport packet is illustrated in FIG. 1a. The transport packet 100 is typically 188 bytes long, beginning with a 4-byte header 10, with the remaining 184 bytes known as the payload. The first byte 120 of the header 10 is the synchronization byte, typically also referred to as the sync byte, which has a synchronization pattern 0x47. The remaining three bytes of the header are for other purposes.
DVB decoder systems have an interface to a tuner circuit that is typically 8-bit parallel. The tuner drives the data along with a clock and data valid signal that is used by the DVB system. The incoming data into the DVB system is asynchronous to the DVB system. Because of this, the DVB system needs to establish the packet boundaries within the transport bitstream, a process known as “synchronization”. The DVB system can attempt to detect the sync byte to identify the start of a packet, and then place the boundaries at 188-byte intervals starting at the detected sync byte.
However, it can occur in some instances that many of the bytes in the packet, in the header or the payload, are 0x47. FIG. 1b illustrates an example transport bitstream 150 in which many of the bytes are 0x47. Attempting to detect the packet boundaries in bitstream 150 and thus synchronize the tuner, a synchronizer will detect that byte 0 is 0x47, and then count the remaining 187 bytes to find the transport packet boundary at byte 188. If this is the correct boundary, then the second packet would start at byte 188 with a sync byte 0x47 of the second packet. But the data at byte 188 is 0x22, so the first 0x47 that was detected (at byte 0) cannot be the start of a packet. Therefore, the synchronizer needs to detect the next incoming 0x47 byte, which happens to be byte 1. However, the second 0x47 byte (byte 1) is already lost because the synchronizer was counting the incoming data from the initially detected 0x47 byte (byte 0). The synchronizer will be able to detect the next 0x47 only after 188 bytes have been counted. It can occur in some instance that the next detected 0x47 is part of the payload and not the actual sync byte. It may therefore take a long time to synchronize the transport bitstream, within which time incoming data can be lost. In some cases it might happen that synchronization cannot be achieved.
A similar disadvantage exists even if the synchronizer counter is reset when a new 0x47 is received. This will overwrite the previously captured sync position. Again referring to FIG. 1b, starting from position 0, the next 0x47 is detected at byte 1 (which is in fact a sync byte), resetting the counter. Now again at byte 3, 0x47 (which is actually a data byte) is detected, once again resetting the counter. Such a resetting procedure will delay the synchronization process or even fail to achieve synchronization.
To achieve fast synchronization, it is necessary to detect occurrences of 0x47 separated by 188 bytes (pairs of sync bytes). A counter has to be started when each 0x47 is detected and the 189th byte checked to see whether it is 0x47 or not. Repeating this exercise for each and every occurrence of 0x47 is difficult and cumbersome to implement in hardware, especially where a continuous flow of data exists. Conventional hardware solutions store 188 bytes at a time in a buffer and then compare the incoming byte with the oldest stored byte to detect the presence of a pair of sync bytes in the data bitstream continuously. A disadvantage with this approach is that it uses a large amount of memory. The buffer may not be used in actual packet processing once the sync pair is detected. In applications where the synchronization is to be implemented in a field programmable gate array (FPGA), the conventional solution is impractical, since FPGAs have strictly limited internal memory.